Listing in BASIC mit eingerücktem linken Rand

Eine Umgehung wäre tatsächlich, das Listing mit LIST "D:program.TXT" abzuspeichern und als Text mit einer Textverarbeitung auszudrucken.

Ich kenne jetzt deinen Drucker nicht so genau, aber ist es nicht möglich das Papier weiter links einzuspannen, dann sollte der Druck doch weiter rechts starten...

Hallo,

bei EPSON und kompatiblen Druckern konnte man per ESC Code (u..a.) den linken Rand einstellen. Allerdings weiß ich nicht, ob das beim Präsidenten auch geht. ESC l (kleines L) war es beim Epson glaube ich. Danach sollten Listings mit dem gesetzten Rand ausgedruckt werden.

Moin, nach ESC l kam noch die Anzahl der einzurückenden Zeichen. Die Syntax müsste auch in alten Handbüchern zu den Epson FX Druckern stehen. Ich schaue heute Abend noch mal nach.

probier mal folgendes

10 LIST "P:"
20 LPRINT CHR$(27);"l";CHR$(10)
30 LIST "P:"
40 LPRINT CHR$(27);"l";CHR$(5)
50 LIST "P:"

dann müßte das Listing einmal linksbündig, einmal mit 10 Zeichen Leerraum vor jeder Zeile und einmal mit 5 Zeichen Leerraum vor jeder Zeile gedruckt werden.

Funktioniert auf ATARI800MacX mit EPSON FX80 einwandfrei.

Bei der von Dir gezeigten 2. Seite sind die Codes Hexadezimal angegeben, z.B. "ESC 0E", das muss dann erst in dezimal umgerechnet werden hex.0E=dez.14 Die CHR$ Befehle im ATARI Basic können nur Dezimalzahlen: CHR$(14) In TURBO-Basic kannst Du auch Hexadezimalzahlen nehmen, dann aber mit "$" vornedran: CHR$($0E)

mach mal hinter die schließende Klammer am Ende der Zeile 20 und 40 noch ein ; (Semikolon) und guck was dann passiert

10 LIST "P:"
20 LPRINT CHR$(27);"l";CHR$(10);
30 LIST "P:"
40 LPRINT CHR$(27);"l";CHR$(5);
50 LIST "P:"

Ich habe einen Drucker, den man im Hex-Dump-Modus starten kann.

Dann kann man im Ausdruck sehen, was der Rechner nun wirklich geschickt hat.

Damit konnte ich früher einen Fehler des Wiesemann-Centronics Interface aufdecken:

Im Grafikmodus übersetzt das Interface das Atari EOL in CR LF.

Im Grafikmodus darf aber keine Übersetzung der Daten erfolgen.

Darüber hinaus bekam der Drucker dann pro in den Bilddaten enthaltenem 155 eben 2 Zeichen.

Da man aber beim Grafikdruck im Befehl angeben muß, wieviele Bytes als Grafikdruck kommen werden ...

PS: bei emulierten Druckern habe ich schon festgestellt, daß unter Umständen nicht alle Fähigkeiten deren Original implementiert wurden.

Der Hexdump sieht korrekt aus, nur dass du versehentlich Kommata statt Strichpunkten verwendet hast.

Wiederhol es nochmal mit

20 PRINT #2;CHR$(27);"l";CHR$(10);"TEST"

Dann müsste es 1B 6C 0A 54 45 53 54 ergeben.

Es muss gehen, ich hatte früher auch nen Präsident 6320 und konnte Listings wie Du es Dir vorstellst, ausdrucken. Leider habe ich den Drucker seit ca. 1995 nicht mehr. Dafür kam ein HP-Lasejet 4L der am Paralellport des 16K Bibomons hing. Auch bei dem ging es per ESC- Steuerbefehlen.

.

Manfredini66 schrieb: Bloß wie interpretiere ich das jetzt? Ist "1B" die 27 und "6C" das kleine l?? Und was bedeuten die Zeichen an Position 11 und 21?

Die $20 sind die durch das Komma verursachten Leerzeichen. Das $0A ist Dein CHR$(10) Das $9B ist das EOL

Und dann noch nachfolgender Schrott aus dem nicht "geflushtem" Puffer.

Insgesamt sind es 40 Bytes und das ist glaube ich genau die Puffergröße für den Drucker auf dem Atari.

Hallo Manfred,

da hast du ein spannendes Thema aufgemacht und ich habe ein paar Male gelesen 💡 und nun doch noch eine Idee 💡 💡 sogar zwei...

Erst einmal diese: versuche es mit dem LPRINT, statt mit PRINT # per zuvor geöffnetem Kanal. So wie Florian in seinem Beispiel, der damit ganz offensichtlich Erfolg hatte.

10 LPRINT CHR$(27);"l";CHR$(10)
20 LIST "P:"

Ich vermute, dass die LPRINT-Anweisung und der LIST-Befehl über die gleiche Ausgabeschiene an den Drucker gehen, aber eben nicht über einen per OPEN-Anweisung geöffneten Kanal.

Bisher habe ich in eine Datei gelistet und diese per BASIC-Progrämmchen Zeilenweise per INPUT aus der Datei und per PRINT zum Drucker gesendet. Blöd war nur, dass über das Druckerzeilenende hinausragende Zeichen zudem abgefangen werden mussten, um dann nicht doch am äußersten linken Blattrand gedruckt zu werden. So hatte ich für kurze Programmzeilen gesorgt 😉

Viele Grüße Stefan

gar keinen mehr, ich habe den virtuellen FX80 im ATARI800MacX benutzt

Die Programme funktionieren, der Hexdump zeigt die erwarteten Bytefolgen.

Schlussfolgerung: Der Drucker ignoriert (zumindest) dieses Epson-Kommando.

Just my €0,02

Ich werde mir mal meine Doku zu den Epson ESC Codes zu Gemüte führen.

Die gibt es allerdings nur in Papierform in einer Schublade zu Hause.

Etwas Geduld.

Ich hab zu Hause einen EPSON EPL 5200, bei dem ich eine FX80 Emulation aktivieren kann,

Ich werde das dann selber einmal testen.

DjayBee schrieb: Die Programme funktionieren, der Hexdump zeigt die erwarteten Bytefolgen.

Schlussfolgerung: Der Drucker ignoriert (zumindest) dieses Epson-Kommando.

Just my €0,02

Ich kann mich partout nicht mehr erinnern, bilde mir aber ein, dass es mit dem Atari-Interface irgendwelche Probleme mit den Escape Codes gab. Bin dann auf das Centronics Interface umgestiegen. Dagegen spricht natürlich, dass der hexdump richtig ist und auch manche Programme richtig drucken.

Oder es liegt doch an den vermaledeiten DIP Schaltern. Es gibt jedenfalls extra einen, der Epson Codes ein und ausschaltet. 13-2 bei 6313 (und 6320?)

. Hallo Manfred

Hast Du nach jedem ändern der DIP-Schalter auch immer den Drucker aus- und wieder eingeschaltet? Meistens werden diese Schalter nur dann abgefragt, wenn der Drucker eingeschaltet wird.

Tschüß

Mathy

.

DjayBee schrieb: Schlussfolgerung: Der Drucker ignoriert (zumindest) dieses Epson-Kommando.

Wenn die ESC-Kommandos im Hex-Dump zu sehen sind ist zumindest davon auszugehen, daß das verwendete Druckerinterface diese auch durchläßt.

. So, ich hab auch mal ein bisschen rumgetestet.

Die Testumgebung bestand aus einem 130XE mit org. OS, dem Wiesemann Druckinterface und einem EPSON EPL-5200 Laserdrucker in FX oder LQ Emulation.

Leider übersetzt das Wiesemann Druckinterface gnadenlos alles unter ASCII 32 oder läßt es gar nicht durch.

Das hab ich aber auch erst mit dem HEX-Dump-Modus des Druckers festgestellt, den ein linker Rand von 10 wurde ignoriert.

Warum? Weil aus der 10 ein $7D wurde. Das ist für einen linken Rand ein zu hoher Wert und wird ignoriert.

Ich habe es dann einmal mit 32 ($20) propiert und der Druck hat funktioniert. Das komplette Listing schön mit linkem Rand - eben fast in Blattmitte beginnend.

Nun hat das Wiesemann Druckinterface intern zwar DIP-Schalter aber meine einer hat die Doku zu dem Interface nicht mehr.

Nun erklärt sich immer noch nicht, warum der o.g. Drucker den Befehl für den linken Rand offenbar ignoriert, denn dort blieb ja laut HEX-Dump die "10" für den linken Rand ja erhalten.

Aber das Atari OS oder das BASIC sind vermutlich völlig unschuldig.

Wenn BASIC den Befehl für den linken Rand verschlucken würde wäre er ja auch im HEX-Dump nicht zu sehen.

Außerdem waren die damals froh, daß sie das BASIC ins ROM bekommen haben. Dem hat sicher keiner EPSON Escape-Codes beigebracht.

Zufällig habe ich kürzlich auch Startexter und den AtariWriter80 benutzen wollen.

Ich hab früher so einiges mit Startexter gemacht - ich wußte überhaupt nicht mehr damit umzugehen. Allein die Disk - und Dateihandhabung....

AtariWriter80 sendet wohl eher keine Epson Escape-Code sondern fügt einfach eine entsprechende Zahl von Leerzeichen ein, oder?

Über die XEP80 macht er ja so ein bisschen WYSIWYG und da sind Leerzeichen im Speichermanagement sicher einfacher.

Aber das müßte man halt nochmal via HEX-Dump kontrollieren.

PS: Falls jemand die Doku zum Wiesemann Druckerinterface hat ...

Ich habe mittlerweile die Doku zum Wiesemann Druckinterface von einem netten Menschen erhalten und mal nachgelesen. Es war so eingestellt, daß genau ein Teil der für den Test mit dem linken Rand benötigten Zeichen umgewandelt wurden. Es gibt eine zweite Einstellung, bei der außer dem Atari-Zeilenende ($9B=155) nichts umgewandelt wird, aber die Einstellung war halt nicht aktiv. Dummerweise reicht selbst diese Einstellung nicht in allen Fällen. Denn wenn man ein Bild druckt und den Drucker dazu in den Bild-Druck-Modus schaltet muß man dem Drucker mitteilen, wie viele Bilddaten kommen. Wenn die Bilddaten dann ein- oder mehrfach den Wert 155 enthalten wird der jedesmal in $0D$0A gewandelt, was aber 2 Bytes sind. Das verfälscht erstens das Bild und zweitens killt es den Druck. Ich weiß noch, wiel lange ich damals gebraucht habe, um von den geschrotteten Ausdrucken auf die Fehlerursache zu kommen. Ich hab danach dann beim Vorhaben eines Bilddrucks die Bilddaten auf dem Atari nach 155 durchsucht und durch ein ähnliches Bitmuster ersetzt.

Cool wäre es gewesen, die Firmware des Druckinterface so zu ändern, daß die alle Daten so mitliest, daß sie mitbekommt, wenn die Sequenz für Bilddatendruck kommt und dann für das folgende Datenvolumen die EOL->CR/LF Umwandlung nicht durchführt.

Alternativ eine Einstellung, wo gar nicht gewandelt wird. Dann müßte der Atari sich halt um die EOL->CR/LF Umwandlung kümmern.